When a user browses a web site, the communications path from the client to the web server hosting the web site sometimes suffers from high latency conditions. For example, communicating with a geographically distant web server may correspond to a latency time on the order of one-half a second. The result is a poor user experience reflected by a long delay before pages are displayed. This is often the situation with intranet web sites located on main offices (or headquarters) when accessed from a remote branch office, because in a typical main office/branch office deployment, there is usually only a single instance of an internal web server, and it may be geographically far away from remote clients.
One of the reasons for such a long delay is the serialized way web browsers download web content. More particularly, according to the RFC2616 standard, web browsers should have up to two concurrent connections to each domain. Because contemporary web pages tend to include several embedded objects including icons, text, images, scripts and CSS (cascading style sheet) files, the web browser needs to trigger several HTTP requests to get all of the objects. With a limit of up to two concurrent connections, this can take a relatively long time.
Typical web proxies do not solve this problem when they do not have the requested content cached, such as when the content has not been previously requested, or when it cannot be cached, e.g., because the internal web site requires user authentication as it includes sensitive/restricted company data. For example, consider a user located in a branch office accessing an intranet web site hosted by a web server located at a geographically remote data center or office headquarters. In this example, the connection between the branch office and the headquarters has a latency (or round trip time) of 300 milliseconds. When the web browser downloads the main web page, the browser recognizes that fifty additional embedded objects need to be downloaded. Assuming this is done using two concurrent connections as specified by the RFC2616 standard, only two objects may be requested at a time, whereby twenty-five additional more round trip times are required before the page can be fully displayed. With a latency of 300 milliseconds, obtaining the main web page's full set of content takes approximately seven-and-a-half seconds, which provides a poor user experience.